Skip to main content
Running Strix with local models allows for completely offline, privacy-first security assessments. Data never leaves your machine, making this ideal for sensitive internal networks or air-gapped environments.

​
Privacy vs Performance

Compatibility Note: Strix relies on advanced agentic capabilities (tool use, multi-step planning, self-correction). Most local models, especially those under 70B parameters, struggle with these complex tasks.For critical assessments, we strongly recommend using state-of-the-art cloud models like Claude 4.5 Sonnet or GPT-5. Use local models only when privacy is the absolute priority.

​
Ollama

Ollama is the easiest way to run local models on macOS, Linux, and Windows.

​
Setup

  1. Install Ollama from ollama.ai
  2. Pull a high-performance model:
  3. Configure Strix:
We recommend these models for the best balance of reasoning and tool use: Recommended models:
  • Qwen3 VL (ollama pull qwen3-vl)
  • DeepSeek V3.1 (ollama pull deepseek-v3.1)
  • Devstral 2 (ollama pull devstral-2)

​
LM Studio / OpenAI Compatible

If you use LM Studio, vLLM, or other runners:

​
Gateways that require custom headers

Some OpenAI-compatible gateways require extra HTTP headers (for attribution or tenant routing) alongside the bearer token. Set them with LLM_EXTRA_HEADERS as a JSON object — they are sent on every request:

​
Extra request-body fields

Some provider parameters go in the request body rather than a header, and Strix has no dedicated setting for them. Set them with LLM_EXTRA_BODY as a JSON object — they are merged into the body of every request to the model. For example, to use OpenAI’s cheaper flex processing and attribute requests to a user with a safety identifier (a hash, never a raw email):
Fields aren’t validated, so use only fields your provider accepts, and don’t set fields Strix already sends, such as model, messages or stream. For endpoints behind a private CA, point Strix at your certificate bundle with the standard SSL_CERT_FILE=/path/to/ca-bundle.pem — never disable TLS verification against a real endpoint.

​
Tool calling must return structured tool_calls

Strix is entirely tool-driven: every working turn must be a native function/tool call. If your inference server returns the tool call as plain assistant text instead of a structured tool_calls field, Strix never sees a call it can execute, so the agent makes no real progress — it re-prompts the model for a tool call and gives up once its recovery attempts are exhausted. This is almost always an inference-server configuration problem, not a model or Strix problem. Common symptoms are the model printing a call as text such as:
The fix belongs on the inference server: it must be configured to parse the model’s tool tokens into structured tool_calls. A correctly configured endpoint either returns a structured call or rejects the request outright — it never leaks the call as text.

​
Fixes by server

llama.cpp (llama-server)
  • Run with --jinja and a correct tool-use chat template (--chat-template / --chat-template-file matching the model). Recent builds enable --jinja by default — upgrade if yours doesn’t.
  • For thinking models, align or disable reasoning (--reasoning-format, -rea off) so it doesn’t break tool-call parsing.
  • A low temperature (e.g. --temp 0.2) improves tool-call reliability.
Ollama
  • Use a recent Ollama and a model whose template wires tools. Modern Ollama refuses tools (tools param requires --jinja flag) if the template lacks tool support.
  • For reasoning models (e.g. qwen3), disable the model’s thinking mode — thinking left on frequently pushes the tool call into the text content instead of the structured tool_calls field. Turn it off on the Ollama side (a non-thinking model variant, or think: false in the model’s parameters / Modelfile).
  • Raise num_ctx to at least 16k–32k. Strix sends a large system prompt plus many tool schemas; at Ollama’s small default context the tool definitions are truncated out of the prompt and the model stops emitting valid calls. A short test prompt can look fine while a real scan fails, so set this explicitly rather than inferring it from a quick check.
vLLM
  • Start with --enable-auto-tool-choice, a matching --tool-call-parser (hermes, qwen3_xml, or llama3_json), and a matching --reasoning-parser for reasoning models.
A low sampling temperature (roughly 0.2–0.6, depending on the family) also measurably reduces malformed tool calls on open-weight models. Set it on the server or in your model’s parameters.
Even correctly configured, small models (< ~30B) emit malformed or text-form tool calls far more often than frontier models. Prefer a capable model for reliable agentic behavior.